fix(review): repair stale gate-check publication state - #2351
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2351 +/- ##
==========================================
+ Coverage 95.73% 95.78% +0.05%
==========================================
Files 223 224 +1
Lines 24755 24917 +162
Branches 8970 9056 +86
==========================================
+ Hits 23699 23867 +168
+ Misses 433 428 -5
+ Partials 623 622 -1
🚀 New features to boost your workflow:
|
d7eb457 to
7149942
Compare
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-01 19:21:29 UTC
⏸️ Suggested Action - Manual Review
Review summary Blockers
Nits — 6 non-blocking
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
7149942 to
903cf4c
Compare
903cf4c to
d4abb3c
Compare
The AI-review cache fingerprint only recorded Boolean(REES_URL), so changing the configured analyzer endpoint from one URL to another kept the same cache key -- a same-head PR could reuse AI-review output produced against a different analyzer service. Fingerprint the URL value itself (still one-way-hashed by aiReviewInputFingerprint, so it never appears in the output), matching the pattern already used for the other REES_* fields.
While an active per-PR regate backlog defers ordinary stale maintenance (the point of the earlier check), a repo with even one priority repair (a PR missing its current Gate check) escaped that deferral entirely and picked up a full SWEEP_MAX_PRS batch -- letting unrelated ordinary stale PRs ride along whenever any priority repair existed, contradicting the "normal maintenance yields behind repairs" intent. Cap the candidate limit to exactly the priority count when a backlog is active; a repo with no backlog still gets a normal, full-size sweep. Also documents (not fixes -- verified as a false positive) why `decision.willLabel` in the incomplete-surface audit path is safe even though `decision` can still be the un-reassigned `prelim` value there: `willLabel` is a non-optional boolean on every PublicSurfaceDecision variant, and the path is only reachable when "label" was never in prelim.actions to begin with.
…unreachable runAiReviewForAdvisory is the sole assignment site reaching the cache-write branch, and every one of its "ok" returns sets metadata explicitly, so the nullish fallback is a type-level safeguard only.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
gittensory-ui | ede5fa1 | Commit Preview URL Branch Preview URL |
Jul 01 2026, 07:13 PM |
Summary
What changed
Gittensory Orb Review Agentsummaries after publishing Gate checks.Why
Required Gate checks could remain in GitHub as
Expected — Waiting for status to be reportedwhen local publication state was stale or a webhook was missed. The scheduler also repaired only a small stale batch per pass, so one repo could leave current-head required statuses stranded behind unrelated maintenance backlog.Validation
npx vitest run test/unit/agent-sweep.test.ts test/unit/queue.test.ts test/unit/ai-review-cache.test.tsnpm run typecheckgit diff --checkNotes